1. Field of the Invention
This invention relates to computer program run time libraries, and more particularly to dynamically linking run time libraries to application programs.
2. Description of the Related Art
Traditionally, programming languages do not link-edit all of the support required by an application program into one monolithic load module. Instead, they supply run time libraries which an application program will use at run-time. These Run Time Libraries (RTL) are separately shipped modules which are dynamically linked with application programs when they are run. Finding and associating Run Time Libraries with an application program are done by a language environment. Examples of such a conventional approach are the "IBM LANGUAGE ENVIRONMENT FOR MVS" and the "IBM LE/370" ("IBM" and "LANGUAGE ENVIRONMENT" are registered trademarks and "LE/370" is a trademark of the International Business Machines Corporation).
The method used by conventional systems for finding and associating an application program with its Run Time Libraries may manifest itself in two different scenarios at run time. These two conventional scenarios for finding and using Run Time Libraries are similar, except for the resultant location of the Run Time Libraries in memory. In the first scenario, an application program may be started specifying a Run Time Library to be loaded into the application program's private region of an address space where it may not be shared by other application programs running in the system. In the second scenario, the Run Time Library is pre-installed into a common region of memory where it can be seen and shared by other application programs running in the system.
There are advantages and disadvantages to both of the above scenarios. Common region resident Run Time Libraries result in better performance, because the operating system loads them at system initialization and does not load them from disk afterwards when they are needed by an application program; whereas private region Run Time Libraries are loaded each time they are needed by an application program. However, if two versions of a Run Time Library are needed in the system at the same, only one version can reside in the common region, and the other version must reside in a private region. A conventional mechanism for specifying that a Run Time Library is to reside in a private region is Job Control Language (JCL), which is a usability problem since there exists separate JCL for every application program. These conventional systems do not provide centralized usage of various Run Time Library versions.
There are performance, usability, and functional deficiencies in these traditional methods. As Run Time Library usage is specified for the operating system and for each application program, this information is widely dispersed throughout the system. Upgrading or migrating to a new version of a Run Time Library requires changes to this widely dispersed information.
Traditional systems do not allow multiple versions of Run Time Libraries to reside in a common region of storage, thus resulting in multiple copies of a Run Time Library residing in multiple private regions of storage. These multiple copies require greater system resources than a single copy, (i.e., more storage, more RTL loads, more RTL initializations, longer application program initializations, and reduced application program private region storage).
Traditional systems do not provide for optional use of common storage or private storage.
In view of the above performance, usability, and functional deficiencies of traditional systems, there is a need for a method of, system for, and computer program product for providing a central repository for information regarding Run Time Library usage.